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The  Work-Centered 
Support  System 
approach  to  human- 
centered  computing 
focuses  on  analyzing 
and  supporting  the 
multiple  facets  of  work. 

The  WCSS  for  Global 
Weather  Management, 
developed  to  support 
weather  forecasting 
and  monitoring  in  an 
airlift  service 
organization, 
exemplifies  this 
approach. 


A  hallmark  of  human-centered  computing  (HCC)  is  its  focus  on  domain  practi¬ 
tioners  and  their  field  of  practice.1’2  Human-centered  design  depends  on  a  deep 
analysis  of  a  field’s  cognitive  and  collaborative  demands  and  how  people  work  individu¬ 
ally,  in  groups,  and  in  organizations  to  meet  those  demands.3,4  The  objective  is  to  leverage 


what  we  know  about  human  cognitive  and  collabo¬ 
rative  processes  to  create  systems  that  optimize  the 
affordances  (direct  perception  of  meanings)  and 
effectivities  (knowledge-driven  actions)  for  humans.5 

We  developed  a  software-agent-based  system  for 
weather  forecasting  and  monitoring  that  exemplifies 
the  HCC  approach  and  demonstrates  work-centered 
support  systems  concepts.6-®  The  WCSS  paradigm 
offers  an  approach  for  incorporating  software  agent 
technology  in  a  manner  that  helps  the  user  keep  his  or 
her  “head  in  the  work”  and  reduces  the  possibility 
that  software  agent  states  or  actions  will  surprise  the 
user.  To  date,  software-agent  technology  has  focused 
largely  on  increased  autonomy  of  individual  software 
agents  and  increased  coordination  of  activity  among 
multiple  software  agents.9  As  the  technology  matures, 
we  need  to  focus  on  how  to  integrate  agents  into 
teams  that  include  both  humans  and  agents  and  how 
best  to  deploy  agents  to  support  human  work.10,11 

Work-centered  support  systems 

A  distinguishing  characteristic  of  WCSSs  is  that 


they  focus  on  supporting  all  facets  of  work.  Specif¬ 
ically,  a  WCSS  includes 

•  decision  support  aiding  problem  solving  and  other 
cognitive  work  processes, 

•  product  development  support  aiding  deliverable 
work  artifacts’  production, 

•  collaborative  support  aiding  team  and  colleague 
interactions,  and 

•  work  management  support  aiding  the  metacogni- 
tive  activities  entailed  in  prioritizing  and  manag¬ 
ing  multiple  intertwined  work  activities  (such  as 
requirements  for  attention  shift  and  remembering 
the  number  and  state  of  tasks  in  process). 

A  WCSS  attempts  to  integrate  support  for  each  of 
these  areas  through  the  principle  of  joint  aiding — the 
coordinated  use  of  direct  and  indirect  aiding  methods 
within  a  common,  work-centered  ontology.7  A  coor¬ 
dinated  set  of  software  agents  that  interact  with  the 
user  and  are  clearly  connected  to  or  embedded  in 
work  domain  visualizations  provide  direct  aiding. 
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Indirect  aiding  is  provided  largely  through 
the  creation  of  work  domain  visualizations 
that  reveal  domain  relationships,  constraints, 
and  affordances.  By  emphasizing  the  need  to 
support  all  facets  of  work  and  to  provide 
direct  and  indirect  aiding,  the  WCSS  para¬ 
digm  falls  squarely  within  the  HCC  tradition. 

Designing  a  WCSS 

We  developed  the  Work-Centered  Support 
System  for  Global  Weather  Management 
(WCSS-GWM)  to  support  weather  forecast¬ 
ing  and  monitoring  in  a  military  airlift  ser¬ 
vice  organization.  Building  a  WCSS  requires 
a  development  process  that  grounds  system 
requirements  in  a  deep  understanding  of  the 
cognitive  and  collaborative  demands  of  the 
work  domain.  We  achieved  this  through  close 
collaboration  among  cognitive  and  software 
engineers  and  end-user  domain  practitioners, 
all  of  whom  were  involved  from  the  project’s 
inception.  The  collective  goal  was  to  under¬ 
stand  the  workspace  (work  demands  and 
practices  in  the  environment)  and  stretch 
what  we  already  knew  how  to  do  to  build  a 
new  work  environment — a  collaborative 
effort  in  envisioning,  creating,  and  refining 
a  new  workspace. 

Our  project's  background 

Traditionally,  airlift  pilots  have  been 
responsible  for  their  own  flight  planning, 
including  obtaining  preflight  weather  brief¬ 
ings.  The  organization  we  worked  with  initi¬ 
ated  a  new  approach  to  reduce  the  amount  of 
time  an  aircrew  must  devote  to  these  tasks. 
It  created  a  flight  manager  (FM)  position 
with  the  primary  responsibility  of  planning 
and  managing  multiple  flights,  both  preflight 
and  en  route.  This  includes  obtaining  a 
weather  briefing  and  providing  a  complete 
flight  plan  to  the  pilot,  including  weather 
forecast  information.  The  FM  is  a  virtual 
crew  member  who  supports  the  pilot 

Weather  can  significantly  influence  pre¬ 
flight  and  en  route  flight  management  deci¬ 
sions  (for  example,  accelerating,  delaying, 
or  rerouting  a  flight  because  of  unfavorable 
weather  conditions).  So,  weather  forecasters 
must  work  closely  with  the  FM  to  evaluate 
weather  conditions  at  the  departure  and 
arrival  airfields  and  along  the  planned  route. 
We  focused  on  developing  an  intelligent  sys¬ 
tem  to  aid  near-term  weather  forecasting  to 
support  planning  and  managing  airlifts. 

Cognitive  analysis 

Our  WCSS  methodology  emphasizes 
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acquiring  an  understanding  of  work  as  prac¬ 
ticed  Field  observations  and  interviews 
intended  to  help  us  understand  the  cognitive 
and  collaborative  demands  of  the  domain 
were  an  integral  part  of  our  WCSS-GWM 
development  process.12  We  examined  work 
practices  in  terms  of  decision  making,  prod¬ 
uct  development,  collaboration,  and  work 
management  activities.  These  revealed 
aspects  of  cognitive  and  collaborative  work 
that  could  be  more  effectively  supported, 
which  then  guided  the  design  of  the  WCSS- 
GWM  architecture  and  displays. 

We  performed  three  site  visits,  each  two 
to  three  days  long  and  held  approximately 
two  months  apart.  During  these  visits,  we 
interviewed  forecasters,  FMs,  and  senior  per¬ 
sonnel  to  understand  workflow  and  elicit 
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examples  of  the  complications  that  can  arise 
and  increase  task  demands.  We  also  observed 
FMs  and  forecasters  as  they  handled  actual 
flights  during  planning  and  en  route  phases 
to  identify  FM  and  forecaster  activities  and 
sources  of  complexity  that  the  interviews 
didn’t  reveal.  We  sampled  as  broad  a  range 
of  domain  practitioners  and  situations  as 
practical,  including  interviewing  five  or  six 
individuals  during  each  visit,  interviewing 
individuals  with  differing  levels  of  experi¬ 
ence  and  expertise,  and  conducting  observa¬ 
tions  over  several  time  periods  to  sample  dif¬ 
ferent  activity  rhythms  (morning  and  evening 
shifts  as  well  as  shift  turnovers).  Observa¬ 
tions  spanned  routine  and  challenging  cases. 
They  revealed  the  intensive  collaboration  that 
occurs  between  FMs  and  forecasters  when 
weather  conditions  such  as  severe  turbulence 
or  lack  of  anticipated  tailwind  require  mod¬ 
ification  to  planned  flight  routes. 

We  presented  storyboards  (rapidly  devel¬ 
oped  prototypes)  to  FMs  and  forecasters  for 
their  comments,  enabling  them  to  actively  par¬ 
ticipate  in  design.  The  storyboard  prototypes 


embodied  candidate  aiding  concepts  and  dis¬ 
played  increasing  functionality  and  robustness 
with  each  site  visit,  reflecting  what  we’d 
learned  from  die  prior  visit  They  provided  a 
concrete  vehicle  to  demonstrate  our  growing 
understanding  and  to  obtain  user  feedback  on 
the  evolving  aiding  concepts’  viability.  They 
also  provided  a  stimulus  for  raising  additional 
domain  constraints  and  complications  that 
we’d  need  to  accommodate. 

A  multidisciplinary  team — including  cog¬ 
nitive  engineers  experienced  in  domain 
analysis  and  user  requirements  specification 
and  software  engineers  who  would  design 
and  implement  the  software — conducted  the 
field  observations  and  interviews.  The  par¬ 
ticipation  of  both  cognitive  and  software 
engineers  facilitated  dialogue  among  the 
team  members  and  enabled  close  collabora¬ 
tion  in  the  specification  and  design  of  the 
WCSS-GWM  system  architecture  and  user 
interface. 

Workspace  and  work  pattern 
observations 

Typically,  three  trained  forecasters  are  on 
duty  each  shift  in  the  organization  we  stud¬ 
ied.  Two  sit  in  a  weather-forecasting  room 
adjacent  to  and  within  sight  of  the  FMs’  area, 
and  one  sits  in  the  flight  management  area  to 
provide  collaborative  support  to  the  FMs.  The 
weather-forecasting  room  includes  numerous 
workstations,  each  with  two  or  three  CRTs, 
and  several  wall-mounted  TV  monitors  and 
large-screen  displays  that  can  be  slaved  to 
some  of  the  workstation  screens.  As  a  matter 
of  standard  practice,  the  large-screen  panels 
display  loops  of  weather  satellite  imagery, 
focused  on  geographic  regions  of  interest. 
They  are  also  used  to  present  weather  brief¬ 
ings  to  FMs  during  shift  changes,  as  well  as 
to  support  forecaster  collaboration. 

The  forecasters  focus  on  near-term  avia¬ 
tion  weather  forecasting — understanding  and 
predicting  weather  conditions  that  will  affect 
flights  in  the  air  and  those  scheduled  to  take 
off  in  the  next  12  hours.  Near-term  forecast¬ 
ing  requires  acquiring,  interpreting,  and  inte¬ 
grating  multiple  weather  data  types,  includ¬ 
ing  satellite  imagery,  airfield  and  other 
observations  (such  as  pilot  reports  of  turbu¬ 
lence),  upper-air  forecasts,  and  computer 
model  projections  from  local  and  worldwide 
sources.  These  weather  data  types  were  typ¬ 
ically  available  to  the  forecasters  from  sepa¬ 
rate  Web  pages  or  map  displays,  requiring 
forecasters  to  mentally  integrate  information 
from  multiple  disparate  sources. 
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In  many  cases,  the  available  data  are 
incomplete,  ambiguous,  stale,  or  conflicting. 
Weather-forecasting  expertise  includes  the 
abilities  to  look  for  convergence  among  mul¬ 
tiple  data  types  (to  check  that  “things  are  lin¬ 
ing  up”)  and  pursue  additional  sources  of  evi¬ 
dence  to  fill  in  missing  data  or  resolve 
ambiguous  or  conflicting  data.  For  example, 
a  forecaster  can  increase  confidence  in  a  fore¬ 
cast  by  checking  with  a  location  in  a  pre¬ 
dicted  storm’s  path  to  confirm  that  the  storm 
has  materialized.  Similarly,  the  forecaster  can 
increase  confidence  in  a  turbulence  predic¬ 
tion  by  checking  certain  kinds  of  satellite 
imagery  and  seeking  pilot  reports  (Pireps) 
confirming  actual  conditions. 

We  observed  several  cases  where  fore¬ 
casters  had  to  reconcile  conflicting  forecasts, 
including  cases  where  the  forecaster  needed 
to  call  the  forecast’s  source  to  understand  the 
■basis  for  a  prediction.  In  at  least  one  case,  the 
forecaster  had  to  advocate  an  alternative  fore¬ 
cast.  Being  able  to  resolve  ambiguous  or  con¬ 
flicting  weather  data  is  critical  because  pre¬ 
dicting  severe  weather  has  risk/benefit 
consequences.  Being  too  conservative  can 
mean  serious  delays  or  cancelled  missions; 
being  insufficiently  conservative  can  result  in 
costly  mission  diversions,  plane  damage,  or 
even  risk  to  life.  To  minimize  the  impact  on 
mission  objectives,  forecasters  are  sensitive  to 
both  of  these  concerns  and  work  intensely  to 
refine  their  forecasts  and  communicate  to  FMs 
the  basis  of  and  level  of  confidence  in  weather 
predictions.  They  must  also  identify  ways  to 
work  around  real  or  anticipated  weather  haz¬ 
ards — for  example,  by  selecting  alternate  take¬ 
off  or  landing  airfields  or  changing  the  takeoff 
time  or  flight  route. 

Our  analysis  revealed  that  FMs  and  fore¬ 
casters  operate  as  a  team  to  manage  the  air¬ 
lift  missions  in  their  work  queue.  The  FM  is 
the  primary  player,  constructing  flight  plans, 
preparing  crew  papers,  and  monitoring  the 
many  details  involved  in  ensuring  each  mis¬ 
sion’s  success.  The  forecasters  engaged  in 
multiple  activities: 

•  maintaining  situational  awareness  of 
weather  conditions  in  multiple  geographic 
regions  worldwide, 

•  preparing  general  forecasts  for  these 
regions  and  tailored  forecasts  for  each  mis¬ 
sion, 

•  responding  to  requests  and  providing 
timely  weather  data  to  various  parties  in 
the  organization  (including  pilots  who  call 
for  weather  updates), 


•  monitoring  weather  observations  to  assess 
their  effects  on  current  and  upcoming 
missions, 

•  helping  FMs  develop  options  for  working 
around  hazardous  weather  to  minimize  its 
impact  on  mission  goals,  and 

•  negotiating  with  other  weather-forecast¬ 
ing  organizations  regarding  the  appropri¬ 
ate  interpretation  of  ambiguous  weather 
data  and  advocating  particular  weather 
inteipretations. 

FMs  and  forecasters  worked  collabora- 
tively  to  understand  the  consequences  of 
unexpected  situations  (such  as  changing  mis¬ 
sion  requirements  or  weather  conditions)  and 
determine  appropriate  action  (such  as  delay¬ 


ing  or  rerouting  a  flight  or  changing  the  fuel 
load  or  cargo). 

Identifying  leverage  points — 
opportunities  to  provide  support 

Our  analysis  identified  a  number  of  lever¬ 
age  points  or  opportunities  to  more  effec¬ 
tively  support  weather  forecasting  and  mon¬ 
itoring.  This  provided  the  basis  for  defining 
work-centered  support  requirements. 

Decision  support  Forecasters  can  use  sup¬ 
port  in  collating  and  integrating  information 
from  multiple,  disparate  aviation  weather 
sources,  including  forecasts,  satellite  imageiy, 
real-time  weather  updates,  and  particularly 
flight  plans  for  current  and  near-term  flights. 
This  can  be  accomplished  by  integrating  the 
multiple  weather  sources  on  a  single  georef- 
erenced  map.13  Providing  an  integrated  visu¬ 
alization  enables  forecasters  to  more  quickly 
derive  and  update  a  situation  model  of  sig¬ 
nificant  weather  factors  in  their  geographic 
areas  of  responsibility.  This  supports  the  gen¬ 


eral  requirement  for  forecasters  to  achieve 
and  maintain  weather-related  situational 
awareness  so  that  they  can  make  sound  deci¬ 
sions.  An  integrated  visualization  provides 
more  effective  support  for  the  cognitively 
challenging  aspects  of  forecasting:  identify¬ 
ing  converging  evidence  in  support  of  a  fore¬ 
cast  and  identifying  and  resolving  ambigu¬ 
ous  or  conflicting  information. 

Product  development  The  process  by  which 
forecasters  update  and  revise  forecasts  is 
labor  intensive,  so  they  don’t  update  them  as 
often  as  they’d  like.  Tools  that  enable  more 
rapid  recognition  of  changes  in  weather  con¬ 
ditions  and  production  of  revised  forecasts 
would  enhance  both  forecasts’  accuracy  and 
timeliness. 

Collaboration  support.  The  forecaster-FM 
team  needs  collaborative  support  in  evaluat¬ 
ing  weather’s  impact  on  flight  plans  and  mak¬ 
ing  reroute  decisions.  Weather  and  flight  infor¬ 
mation  aren’t  well  integrated.  The  forecaster 
has  the  best  access  to  weather  information, 
and  the  FM  has  the  best  access  to  planned 
and  en  route  flights’  status.  Superimposing 
weather  and  flight  information  (for  example, 
the  flight  route  and  organized  tracks  that  con¬ 
stitute  legal  flight  path  options)  on  a  single 
georeferenced  map  that  the  FM  and  forecaster 
can  view  simultaneously  would  let  them  visu¬ 
alize  the  weather’s  impact  on  a  flight  route  and 
collaboratively  formulate  reroute  options. 

Work  management  support.  Forecasters 
must  monitor  weather  conditions  in  multiple 
geographic  regions  of  interest  and  support 
planning  and  monitoring  of  tens  of  flights. 
Notifying  the  forecaster  and  FM  of  signifi¬ 
cant  changes  in  weather  conditions  and  the 
missions  that  weather  changes  will  affect  can 
help  direct  their  attention  to  potentially  high- 
risk  flights.  Further,  mechanisms  that  sup¬ 
port  keeping  track  of  missions  to  be  moni¬ 
tored  and  easily  shifting  back  and  forth 
among  them  are  important  to  support  the 
multiple  interwoven  activities  that  charac¬ 
terize  forecasters’  work. 

Using  software  agent  technology 
to  create  a  WCSS 

The  WCSS-GWM  focused  on  monitoring 
the  status  of  en  route  and  near-takeoff  mis¬ 
sions  with  respect  to  weather  conditions  and 
on  achieving  and  maintaining  weather- 
related  situational  awareness  for  geographic 
regions  of  interest. 
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Figure  1.  The  Work-Centered  Support  System  for  Global  Weather  Management's  map  display  and  floating  Sortie  Palette. 


Our  investigation  into  how  weather  per¬ 
sonnel  performed  these  tasks  suggested 
which  weather  data  types  would  be  useful. 
The  weather  personnel  already  used  some  of 
these  data  types.  In  some  cases,  weather  per¬ 
sonnel  evaluated  graphic  images,  and  we’d 
have  to  analyze  the  underlying  numerical 
data  to  achieve  the  same  effect.  To  meet  our 
design  objectives,  the  WCSS-GWM  required 
these  functionalities: 

•  acquisition  of  real-time  weather  observa¬ 
tions,  such  as  Pireps  and  automated  obser¬ 
vations  of  wind  and  turbulence  information 
sent  through  the  Aircraft  Communication 
and  Reporting  System  (Acars). 

•  acquisition  of  worldwide  airfield  and 
upper-air  forecasts  produced  locally  and 
remotely.  These  include  Significant  Mete¬ 
orological  Information  bulletins  (SiGMErs), 
which  describe  areas  with  weather  that's 
potentially  hazardous  to  aviation;  Meteo¬ 
rological  Terminal  Air  Reports  (Metars), 
which  describe  current  surface  weather 
observations  at  worldwide  reporting  sta¬ 
tions;  and  terminal  area  forecasts  (TAFs), 
which  are  bulletins  that  give  surface 


weather  forecasts  for  worldwide  reporting 
stations. 

•  graphical  integration  of  multiple  data 
sources  including  maps,  flight  plans,  fore¬ 
casts,  point  observations,  and  satellite 
imagery.  An  important  design  requirement 
was  die  ability  to  easily  overlay  any  sub¬ 
set  of  data  types  on  the  same  georefer- 
enced  map  for  comparison  purposes. 

•  automated  comparison  of  real-time 
weather  observations  with  user-defined 
geographical  areas  of  interest  (referred 
to  as  watch  areas)  and  alerts  to  focus 
forecaster  attention  on  operationally  rel¬ 
evant  changes  in  weather  conditions. 
Achieving  a  general  capability  for  an 
automated  alerting  process  would  be  dif¬ 
ficult.  So,  we  limited  alerting  to  specific, 
useful  capabilities,  such  as  generating 
an  alert  for  any  report  from  Pireps  or 
Acars  of  turbulence  or  icing  of  at  least 
a  defined  severity  level  in  the  defined 
region  of  interest  (latitude,  longitude, 
altitude,  or  time). 

•  automated  and  directed  monitoring  of 
individual  missions  and  watch  areas,  as 
well  as  generation  of  alerts  to  focus  user 


attention  on  changes  in  weather  conditions 

that  can  affect  flights. 

The  prototype  we  developed  includes  a 
centrally  located,  georeferenced-map-based 
visualization  as  a  framework  for  providing 
direct  and  indirect  aiding.  Users  can  selec¬ 
tively  superimpose  a  variety  of  weather  and 
flight  plan  information  on  the  map.  Weather- 
related  alerts  generated  by  software  agents 
are  presented  at  their  geolocations  on  the 
map.  The  display  is  built  on  top  of  OpenMap, 
an  open-source,  Java-based,  geospatial  dis¬ 
play  toolkit  (see  http://openmap.bbn.com). 
Figure  1  illustrates  the  WCSS-GWM’s  basic 
features. 

The  WCSS-GWM’s  “home  view”  is  a 
map  showing  the  geographical  area  of  inter¬ 
est,  surrounded  by  controls.  The  map  con¬ 
trols  let  you  pan,  zoom,  and  change  projec¬ 
tions,  while  layer  controls  let  you  view 
multiple  layers  of  flight  and  weather  infor¬ 
mation  on  the  map.  You  can  place  flight 
plans,  Pireps,  Acars,  observations,  Sigmets, 
and  satellite  images  on  the  map  and  remove 
them.  An  altitude  slider  control  lets  you  fil¬ 
ter  observations  by  specifying  the  altitude. 
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You  can  access  more  details  by  hovering  over 
an  icon;  for  example,  you  can  obtain  a  Pirep’s 
text  by  placing  the  cursor  over  the  Pirep  sym¬ 
bol  on  the  map. 

A  floating  Sortie  Palette  lists  all  missions 
of  interest  and  summarizes  individual  mis¬ 
sions’  status.  It  provides  the  abilities  to  high¬ 
light  and  locate  specific  missions  and  to  sort 
and  organize  them  to  suit  the  work  context. 
It  also  lets  users  maintain  awareness  of 
weather-related  alerts,  keeping  track  of 
which  ones  they’ve  already  viewed  and 
which  ones  they  must  still  deal  with.  Fur¬ 
thermore,  it’s  integrated  with  the  map  dis¬ 
play  such  that  you  can  highlight  problem 
notifications  on  the  map  with  a  simple  button 
click  on  the  palette.  Thus,  the  Sortie  Palette 
aids  work  management  for  work  on  a  given 
mission  or  a  set  of  missions. 

Software  agents'  role 

Software  agents  provide  intelligent  auto¬ 
mation  to  directly  support  forecasters.  The 
WCSS-GWM  includes  agents  that  monitor 
missions  and  geographic  regions  of  interest 
and  notify  the  forecaster  when  operationally 
significant  weather  changes  occur.  A  key 
WCSS-GWM  design  element  is  that  the  fore¬ 
caster  can  create,  monitor,  and  modify  these 
agents.  For  example,  the  forecaster  can  create 
an  agent  by  drawing  a  polygon  around  a 
watch  area  on  the  map  and  specifying  the 
agent  behavior  by  setting  parameters  (desired 
altitude,  start  and  stop  time,  hazard  type,  and 
severity  to  watch  for).  Later,  the  forecaster 
can  modify  the  polygon’s  shape  and  position 
and  modify  the  agent  behavior  by  changing 
the  parameters.  Forecasters  can  also  create 
and  modify  agents  that  monitor  for  weather 
changes  around  a  flight  path. 

Figure  2  illustrates  this  ability  to  create 
and  modify  agents.  The  wide  shading  along 
a  flight  path  indicates  the  geographic  area  an 
agent  is  monitoring.  Similarly,  the  transpar¬ 
ent  geometric  shapes  off  the  eastern  US 
coastline  indicate  the  watch  areas  agents  are 
monitoring.  The  Create  Area  and  Edit  Agent 
Parameters  pop-up  windows  illustrate  the 
abilities  to  create  new  agents  and  to  view  and 
modify  the  parameters  that  control  agent 
behavior. 

User  (forecaster)  creation  of  agents  is  an 
important  aspect  of  a  WCSS.  Complex  sys¬ 
tems  with  many  automation  features,  such  as 
auto-assistance  in  different  operational 
modes,  can  lead  to  machine-induced  user 
errors10  in  which  the  user  thinks  the  system 
is  behaving  in  one  way  but  the  automation 
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Figure  2.  A  screen  shot  illustrating  the  ability  to  create  and  modify  software  agents. 


condition  causes  it  to  behave  differently.  Sys¬ 
tem  designers  can  mitigate  this  problem  by 
providing  users  with  the  capability  to  create 
and  set  the  conditions  for  an  agent.  Because 
of  this  involvement  in  specifying  and  acti¬ 
vating  the  automation  protocol,  the  user 
should  have  increased  awareness  of  what  ser¬ 
vice  the  automation  provides. 

The  watch  area  agent  in  Figure  2  is 
expressed  in  work  terms — a  physical  area  to 
be  watched,  indicated  by  the  polygon.  Users 
don’t  have  to  translate  from  an  agent  icon  to 
the  weather-based  semantic  intent  of  what 
assistance  the  agent  provides.  They  observe 
the  agent  directly  in  the  work  ontology,  thereby 
reducing  cognitive  complexity  and  demand. 

The  WCSS-GWM  contains  three  broad 
classes  of  agents.  Acquisition  agents  acquire 
data  from  outside  sources  such  as  weather 
bulletins,  Acars,  Sigmets,  satellite  imagery, 
mission  details,  and  flight  plans.  Each  acqui¬ 
sition  agent  is  responsible  for  a  particular 
data  type  or  source  and  periodically  retrieves 
the  latest  data  from  that  source  (anywhere 
from  once  a  minute  to  once  every  few  hours, 
depending  on  how  often  new  data  are  avail¬ 
able).  Furthermore,  each  acquisition  agent 
signals  other  interested  agents  when  it  has 
retrieved  new  data. 

Analysis  agents  analyze  data  that  acquisi¬ 
tion  agents  have  retrieved  to  produce  initial 
problem  indications  (individual  turbulence 
or  lightning  strike  reports,  intersections  of 


flight  plans  with  Sigmets,  and  so  on).  Fore¬ 
casters  trigger  region  analysis  agents  when 
they  decide  to  monitor  a  geographic  region 
for  critical  conditions  (that  is,  to  create  a 
watch  area)  and  then  watch  for  observations 
matching  given  criteria.  The'presence  of  a 
current  or  upcoming  flight  mission  automat¬ 
ically  generates  mission  analysis  agents, 
which  watch  for  reports  (such  as  Pireps  or 
Acars)  close  to  the  flight  plan  (in  latitude, 
longitude,  altitude,  or  time)  that  significantly 
affect  the  mission. 

Presentation  agents,  based  on  the  analysis 
agents’  results,  decide  what  information  to 
present  to  the  user.  These  agents  work  on  ini¬ 
tial  problem  indications,  clustering  and  prior¬ 
itizing  them  to  create  a  high-level  presenta¬ 
tion  of  problems.  For  example,  the  analysis 
agents  might  generate  many  related  notifica¬ 
tions  that  the  presentation  agents  must  aggre¬ 
gate  into  a  single  notification  message  to  avoid 
an  “alarm  avalanche”  problem14  Presentation 
agents  also  stage  displays — that  is,  they 
retrieve  enough  of  the  right  kind  of  data  so  that 
the  information  the  user  needs  can  be  quickly 
rendered  on  the  screen.  We’ve  implemented 
only  a  limited  presentation  agent  capability 
(as  shown  in  Figure  2),  but  in  a  full-scale 
WCSS-GWM  implementation,  these  agents 
would  have  two  additional  responsibilities: 

•  displaying  data  at  different  levels  of  aggre¬ 
gation,  depending  on  the  user’s  role.  For 
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example,  a  supervisor  might  get  only  a 
top-level  summary  view  of  areas  of  turbu¬ 
lence,  while  the  user  responsible  for  a  par¬ 
ticular  mission  might  see  individual 
reports  of  turbulence  close  to  that  mission 
path.  The  presentation  agent  would  aggre¬ 
gate  the  same  underlying  data  to  different 
levels  for  different  users. 

•  displaying  different  data  depending  on  the 
user’s  role.  In  a  global  system,  multiple 
FMs  and  forecasters  would  split  the  globe 
into  regions  of  responsibility.  As  analysis 
agents  produced  critical  weather  indica¬ 
tions,  a  presentation  agent  would  present 
this  information  only  to  interested  users. 

A  consideration  in  the  agent  architecture 
design  was  to  create  a  structure  that  the  fore¬ 
casters  could  understand,  inspect,  and  mod¬ 
ify.  While  software  agent  research  has 
tended  to  focus  on  the  high-level  tasks  del¬ 
egated  to  agents  and  their  level  of  autonomy, 
agent  technology’s  value  from  a  software 
development  perspective  is  that  software 
agents  are  small,  independent  chunks  of 
software.  Each  addresses  a  small,  unified  set 
of  tasks  and  is  separately  controllable  and 
modifiable.  In  creating  the  agent  architec¬ 
ture,  we  needed  to  structure  the  software  so 
that  the  agents’  capabilities  would  be  mean¬ 
ingful  to  users  in  terms  of  their  work 
domain.  We  configured  the  agents  to  mirror 
the  basic  terms  of  reference  the  users  employ 
in  addressing  their  work.  This  applies  both 
with  respect  to  the  agents’  functions  (such 
as  acquiring,  analyzing,  and  presenting  data) 
and  to  the  domain  objects  the  agents  work 
on  (such  as  missions,  forecasts,  and  watch 
areas).  Once  the  software  is  organized  into 
domain-meaningful  chunks  implemented  as 
agents,  users  can  more  readily  observe  and 
direct  their  operation. 

Using  D-OMAR  to  create  agent- 
based  systems 

We  built  our  agent  system  on  top  of  the 
Distributed  Object  Model  Architecture  sys¬ 
tem,  developed  under  the  Air  Force  Research 
Laboratory’s  sponsorship  (see  http://omar. 
bbn.com).  D-OMAR  was  initially  an  event- 
based  simulator  that  included  representation 
languages  designed  to  facilitate  research  in 
human  performance  modeling.15  It  has 
evolved  into  a  full-featured  distributed  soft¬ 
ware  infrastructure  that  provides  a  broad 
range  of  services  essential  to  agent-based 
system  development.  Agents  must  be  cre¬ 
ated,  be  able  to  launch  procedures  that  imple¬ 


ment  their  services,  and  be  retired  or 
removed  when  no  longer  needed.  A  publish- 
subscribe  protocol  supports  agent  commu¬ 
nication.  In  addition  to  the  basic  function  of 
moving  data  between  agents,  the  publish- 
subscribe  capability  plays  an  essential  role 
in  coordinating  pairs  or  groups  of  agents’ 
activities.  An  agent  can  also  use  the  publish- 
subscribe  protocol  to  coordinate  the  execu¬ 
tion  of  its  multiple  proactive  and  reactive 
behaviors.  We've  found  these  language  fea¬ 
tures  essential  to  the  rapid  development  of 
sophisticated  agent  behaviors. 

Two  implementations  of  D-OMAR  exist: 
the  original  Lisp  implementation,  now  known 
as  OmarL,  and  the  new  Java  implementation, 
OmarJ.  We  developed  the  WCSS-GWM 
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using  OmarJ.  Software  agents  developed  in 
either  environment  have  similar  capabilities; 
indeed,  Java-  and  Lisp-based  agents  are  inter¬ 
operable.  A  procedural  language  supports 
agent  behavior  implementation.  In  OmarL, 
the  Simulation  Core  language  (Score)  was 
built  as  an  extension  of  the  Lisp  language 
itself.  ScoreJ,  a  set  of  Java  class  libraries,  pro¬ 
vides  a  similar  capability  for  Java  imple¬ 
mentations.  Important  language  features 
such  as  roce,  join,  and  satisfy  support  the  devel¬ 
opment  of  concurrent  proactive  and  reactive 
procedures  essential  to  individual  agent 
behaviors.  Time  management  features  such 
as  sleep  support  the  scheduling  of  important 
services,  and  you  can  use  them  with  concur¬ 
rency  control  to  specify  time-out  conditions. 
These  language  features,  used  in  combina¬ 
tion,  can  act  as  pattern  matchers  for  events 
evolving  in  time.  The  languages  also  support 
the  priority-based  mediation  of  contention 
between  specified  subsets  of  procedures. 

The  WCSS-GWM's  status 

The  WCSS-GWM  is  in  the  late  stage  of 


development.  We’ve  installed  it  on  several 
workstations  at  the  airlift  service  facility,  and 
forecasters  are  using  it.  Users  have  reported 
several  cases  where  they  successfully 
rerouted  flights  on  the  basis  of  information 
provided  by  the  WCSS-GWM. 

Implications  of  using  agent 
technology 

Designing  the  WCSS-GWM  required  us 
to  consider  a  number  of  questions  related 
to  integrating  software  agents  into  human- 
centered  computing. 

Observability  and  directability 

A  growing  body  of  cognitive-engineering 
literature  is  showing  that  for  automated 
agents  to  be  effective,  they  must  act  as  team 
players. 10,1 116  For  software  agents  to  become 
team  players,  you  need  to  design  in  two  fun¬ 
damental  characteristics  from  the  begin¬ 
ning — observability  and  directability.  Users 
must  be  able  to  see  what  the  automated 
agents  are  doing  and  understand  what  they’ll 
do  next  relative  to  the  task’s  state.  They  also 
need  to  be  able  to  control  and  redirect  the 
software  agents  as  task  requirements  change. 

We  designed  the  WCSS-GWM  agent- 
based  architecture  with  these  objectives  in 
mind.  The  georeferenced  map  provides  a 
common-ground  representation  of  the  cur¬ 
rent  situation  that’s  available  to  both  humans 
(FMs  and  forecasters)  and  software  agents. 
Furthermore,  the  user  can  see  and  control 
agents’  activities — the  display  presents  the 
geographic  area  the  software  agents  are  mon¬ 
itoring,  and  the  user  can  modify  it.  Similarly, 
the  forecaster  can  inspect  and  modify  the 
weather  parameters  that  the  agents  are  mon¬ 
itoring  and  the  trigger  points  for  alerts. 

Software  agents'  role  in  human- 
centered  systems 

Our  discussion  of  agents  in  the  WCSS- 
GWM  points  to  their  multiple  roles  in 
human-centered  systems’  development.  At 
the  software  development  level,  agent  tech¬ 
nology  is  valuable  because  the  agents  are 
small,  independent  “chunks”  of  software, 
each  of  which  addresses  bounded  tasks.  Soft¬ 
ware  agents  can  be  controlled  and  modified 
separately,  which  greatly  facilitates  software 
development,  maintenance,  and  upgrades. 

From  a  work-centered  perspective,  agents 
are  useful  because  they  enable  the  develop¬ 
ment  team  to  organize  software  components 
around  the  elements  of  work.  A  detailed 
domain  analysis  lets  the  team  map  out  the  work 
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requirements  and  systematically  allocate  tasks 
to  humans  and  software  agents  as  appropriate. 
In  the  domain  of  weather  forecasting  to  sup¬ 
port  flight  management,  the  kinds  of  work  that 
humans  can  allocate  to  software  agents  include 
“watch  this  region  of  the  world  and  let  me 
know  of  any  weather  problems  that  arise” 
(region  analysis  agents),  “watch  this  mission 
for  me  and  let  me  know  of  any  problems  that 
arise”  (mission  analysis  agents),  or  even 
“watch  this  weather  system”  or  “interpret  this 
weather  pattern”  (weather-centered  agents, 
which  we  have  yet  to  implement),  freeing 
human  attention  resources  for  other  tasks. 

A  corollary  of  structuring  agents  in  work 
domain  terms  is  that  the  agents  give  us  a  con¬ 
crete  vocabulary  of  concepts  and  metaphors 
(agents  as  subordinates  to  whom  you  can 
assign  specific  tasks)  that  software  and  cog¬ 
nitive  engineers  and  users  can  share.  This 
facilitates  communication  and  enables  closer 
collaboration  during  system  design. 

Software  agents:  Behind  the 
scenes  or  up  front? 

Closely  related  to  the  question  of  software 
agents’  role  in  human-centered  systems  is  the 
question  of  their  visibility  in  the  interface. 
We  continue  to  struggle  with  the  extent  to 
which  (and  conditions  under  which)  software 
agents  should  have  an  explicit  screen  pres¬ 
ence.  Should  we  treat  software  agents  as  con¬ 
venient  chunks  of  code  that  underlie  system 
functionality  but  have  no  explicit  presence 
in  the  user  interface,  or  should  they  be 
explicit  to  let  users  interact  with  them? 

Multiple  stances  are  possible  on  this  ques¬ 
tion.  At  one  extreme,  you  could  argue  that 
agents  are  a  powerful  tool  for  software  imple¬ 
mentation  but  that  users  should  never  see  or 
hear  about  them  as  such.  Arguments  for  this 
position  include  concerns  that  users  might 
ascribe  a  greater  degree  of  expertise,  compe¬ 
tence,  and  autonomy  to  the  agents  than  is  war¬ 
ranted,  leading  them  to  overly  bust  the  agents. 
Conversely,  ascribing  more  autonomy  to  the 
agents  could  also  cause  users  to  unjustifiably 
mistrust  or  even  fear  them.  At  the  other 
extreme,  you  could  argue  that  if  agents  have 
a  screen  presence  and  even  a  personality 
(such  as  the  animated  Microsoft  paperclip), 
users  can  more  readily  grasp  their  function¬ 
ality,  seeing  them  as  assistants  or  subordinates 
to  whom  they  can  delegate  tasks. 

For  the  WCSS-GWM,  we  chose  a  middle 
ground.  Some  agents  are  visible  in  the  user 
interface,  while  others  operate  behind  the 
scenes.  Agents  with  a  visible  presence  are 


organized  around  domain  work:  the  forecast, 
region,  and  mission  analysis  agents.  Users  del¬ 
egate  work  to  these  agents  that  they  would  oth¬ 
erwise  have  to  do  themselves.  The  agents’ 
presence  in  the  user  interface  lets  users  mon¬ 
itor  and  control  their  performance.  Our  focus 
was  on  letting  users  understand,  observe,  and 
control  the  agents’  behavior.  However,  we 
made  no  attempt  to  personify  these  agents. 
Nothing  marks  them  as  agents  on  the  screen, 
and  they  have  no  personality  or  animated  pres¬ 
ence.  Rather,  we  adopted  a  work-centered  per¬ 
spective  where  users  interact  with  the  inter¬ 
face  and  monitor  and  delegate  tasks  to  agents 
in  the  context  of  performing  their  work. 

Other  agents  in  the  WCSS-GWM  remain 
predominantly  behind  the  scenes,  but  users 


can  access  them  should  the  need  arise.  For 
example,  although  the  data  acquisition  agents 
operate  out  of  sight  most  of  the  time,  fore¬ 
casters  can  bring  up  displays  letting  them 
inspect  and  modify  the  agents’  performance 
as  necessary.  This  becomes  particularly 
important  for  diagnosing  agent  behaviors  (for 
example,  if  a  data  source  accessible  over  the 
Web  goes  down  or  if  data  become  corrupted 
or  stale)  or  tailoring  agent  behaviors  to  new 
circumstances  (for  example,  to  add  or  mod¬ 
ify  a  data  source). 

Finally,  still  other  agents  execute  software 
task  elements,  but  users  can’t  see  or  control 
them.  This  category  includes  the  presenta¬ 
tion  agents,  where  a  need  for  user  interaction 
with  the  agents  hasn’t  yet  emerged. 

Fostering  collaboration  in  system 
design 

We  found  that  an  additional  benefit  of  soft¬ 
ware  agent  technology  is  its  potential  to  facil¬ 
itate  collaboration  among  users  and  cogni¬ 
tive  and  software  engineers.  The  adoption  of 


object-oriented  design  techniques  over  the 
last  10  to  15  years  has  improved  communi¬ 
cation  among  software  and  cognitive  engi¬ 
neers  and  end  users  by  providing  easily 
understandable  descriptions  of  the  domain 
objects’  software  implementation  and  small- 
scale  behavior.  However,  these  descriptions 
have,  at  times,  fallen  short  in  providing  the 
user  with  a  clear  understanding  of  large-scale 
system  behavior — how  objects  hook  together 
to  produce  the  desired  system  results.  As  a 
system  increases  in  complexity,  the  user  can 
easily  lose  the  big  picture  of  how  objects 
work  together,  with  the  result  that  collabora¬ 
tion  between  the  user  and  the  software  devel¬ 
opment  team  effectively  stops. 

The  agent  architecture  provides  the  poten¬ 
tial  for  user-accessible  descriptions  not  only 
of  domain  objects  but  also  of  workflow  and 
large-scale  interactions  between  domain 
objects.  All  members  of  the  team  can  under¬ 
stand  and  contribute  to  the  software’s  design. 
We  expect  that  the  dialogue  among  users  and 
cognitive  and  software  engineers  couched  in 
terms  of  workflow  for  users  and  software 
agents  will  contribute  to  improved  human- 
centered  system  design. 


The  WCSS-GWM  exemplifies  and 
expands  upon  HCC  concepts.  It 
embodies  WCSS  concepts  that  emphasize 
the  need  to  support  the  multiple  facets  of 
individual  cognitive  and  collaborative  work 
through  the  integration  of  software  agents 
that  support  data  acquisition,  analysis,  and 
visualization.  We  successfully  transitioned 
the  WCSS-GWM  into  the  user  organization, 
where  it  underwent  a  formal  evaluation  that 
produced  highly  favorable  results.17  We’re 
continuing  our  research  program  to  develop 
and  exercise  WCSS  design  concepts  and 
principles  through  developing  and  evaluat¬ 
ing  WCSS  applications.  Our  new  research 
effort  targets  the  broader  enterprise  of  flight 
mission  planning  and  execution. 
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